XML Signature (also called XMLDsig, XML-DSig, XML-Sig) defines an XML syntax for digital signatures and is defined in the W3C recommendation XML Signature Syntax and Processing. Functionally, it has much in common with PKCS#7 but is more extensible and geared towards signing XML documents. It is used by various Web technologies such as SOAP, SAML, and others.
XML signatures can be used to sign data–a resource–of any type, typically XML documents, but anything that is accessible via a URL can be signed. An XML signature used to sign a resource outside its containing XML document is called a detached signature; if it is used to sign some part of its containing document, it is called an enveloped signature; if it contains the signed data within itself it is called an enveloping signature.
Contents |
An XML Signature consists of a Signature element in the http://www.w3.org/2000/09/xmldsig# namespace. The basic structure is as follows:
<Signature> <SignedInfo> <CanonicalizationMethod /> <SignatureMethod /> <Reference> <Transforms> <DigestMethod> <DigestValue> </Reference> <Reference /> etc. </SignedInfo> <SignatureValue /> <KeyInfo /> <Object /> </Signature>
DigestMethod specifies the hash algorithm before applying the hash.
DigestValue contains the result of applying the hash algorithm to the transformed resource(s).
When validating an XML Signature, a procedure called Core Validation is followed.
This procedure establishes whether the resources were really signed by the alleged party. However, because of the extensibility of the canonicalization and transform methods, the verifying party must also make sure that what was actually signed or digested is really what was present in the original data, in other words, that the algorithms used there can be trusted not to change the meaning of the signed data.
The creation of XML Signatures is substantially more complex than the creation of an ordinary digital signature because a given XML Document (an "Infoset", in common usage among XML developers) may have more than one legal serialized representation. For example, whitespace inside an XML Element is not syntactically significant, so that <Elem > is syntactically identical to <Elem>.
Since the digital signature is created by using an asymmetric key algorithm (typically RSA) to encrypt the results of running the serialized XML document through a Cryptographic hash function (typically SHA1), a single-byte difference would cause the digital signature to vary.
Moreover, if an XML document is transferred from computer to computer, the line terminator may be changed from CR to LF to CR LF, etc. A program that digests and validates an XML document may later render the XML document in a different way, e.g. adding excess space between attribute definitions with an element definition, or using relative (vs. absolute) URLs, or by reordering namespace definitions. Canonical XML is especially important when an XML Signature refers to a remote document, which may be rendered in time-varying ways by an errant remote server.
To avoid these problems and guarantee that logically-identical XML documents give identical digital signatures, an XML canonicalization transform (frequently abbreviated C14n) is employed when signing XML documents (for signing the SignedInfo, a canonicalization is mandatory). These algorithms guarantee that logically-identical documents produce exactly identical serialized representations.
Another complication arises because of the way that the default canonicalization algorithm handles namespace declarations; frequently a signed XML document needs to be embedded in another document; in this case the original canonicalization algorithm will not yield the same result as if the document is treated alone. For this reason, the so-called Exclusive Canonicalization, which serializes XML namespace declarations independently of the surrounding XML, was created.
XML DSig is more flexible than other forms of digital signatures such as Pretty Good Privacy and Cryptographic Message Syntax, because it does not operate on binary data, but on the XML Infoset, allowing to work on subsets of the data, having various ways to bind the signature and signed information, and perform transformations. Another core concept is canonicalization, that is to sign only the "essence", eliminating meaningless differences like whitespace and line endings.
There are criticisms directed at the architecture of XML security in general,[2] and at the suitability of XML canonicalization in particular as a front end to signing and encrypting XML data due to its complexity, inherent processing requirement, and poor performance characteristics.[3][4][5] The argument is that performing XML canonicalization causes excessive latency that is simply too much to overcome for transactional, performance sensitive SOA applications.
These issues are being addressed in the XML Security Working Group.[6][7]
Another issue is that without proper policy the use of XML Dsig in SOAP and WS-Security can lead to vulnerabilities.[8]
|
|||||||||||||||||||||||||||||||